Search for: All records

Popular platforms for teaching physical computing like the LilyPad Arduino and Adafruit Circuit Playground have simplified programming and wiring, enabling students to quickly engineer physical computing projects. But enabling students to rapidly design and build is a double-edged sword: Students can create functioning prototypes without fully understanding the underlying principles. With limited knowledge and experience, students struggle to locate and fix bugs, or errors, in their projects. Absent appropriate debugging tools, students rely on their instructor for locating errors, or worse, turn toward destructive tactics such as tearing apart and rebuilding their project, hoping the bug fixes itself. Students need tools targeted to their ability that scaffold debugging and help them locate bugs in the mixed hardware/software environment of physical computing. I developed Circuit Check to scaffold the debugging process for students. It enables students to observe real-time sensor data and test hardware components through a novel adaptation of the traditional breakpoint for physical computing. 

Physical computing projects provide rich opportunities for students to design, construct, and program machines that can sense and interact with the environment. However, students engaging in these activities often struggle to decipher the behavior of hardware components, software, and the interaction between the two. I report on the experiences of middle school students using a software tool, Circuit Check, designed to scaffold the debugging process in physical computing systems. Through think-aloud problem-solving exercises, I found Circuit Check facilitated rich instructor-student discussions. Incorporating these preliminary observations, I discuss design considerations for physical computing tools that support productive struggles and student sense-making 

Physical computing projects provide rich opportunities for students to design, construct, and program machines that can sense and interact with the environment. However, students engaging in these activities often struggle to decipher the behavior of hardware components, software, and the interaction between the two. I report on the experiences of middle school students using a software tool, Circuit Check, designed to scaffold the debugging process in physical computing systems. Through think-aloud problem-solving exercises, I found Circuit Check facilitated rich instructor-student discussions. Incorporating these preliminary observations, I discuss design considerations for physical computing tools that support productive struggles and student sense-making 

Abstract Modern surveys of gravitational microlensing events have progressed to detecting thousands per year, and surveys are capable of probing Galactic structure, stellar evolution, lens populations, black hole physics, and the nature of dark matter. One of the key avenues for doing this is the microlensing Einstein radius crossing time ( t E ) distribution. However, systematics in individual light curves as well as oversimplistic modeling can lead to biased results. To address this, we developed a model to simultaneously handle the microlensing parallax due to Earth's motion, systematic instrumental effects, and unlensed stellar variability with a Gaussian process model. We used light curves for nearly 10,000 OGLE-III and -IV Milky Way bulge microlensing events and fit each with our model. We also developed a forward model approach to infer the t E distribution by forward modeling from the data rather than using point estimates from individual events. We find that modeling the variability in the baseline removes a source of significant bias in individual events, and the previous analyses overestimated the number of t E > 100 day events due to their oversimplistic model ignoring parallax effects. We use our fits to identify the hundreds filling a regime in the microlensing parameter space that are 50% pure of black holes. Finally, we have released the largest-ever catalog of Markov Chain Monte Carlo parameter estimates for microlensing events. 

E-textiles, which embed circuitry into textile fabrics, blend art and creative expression with engineering, making it a popular choice for STEAM classrooms [6, 12]. Currently, e-textile development relies on tools intended for traditional embedded systems, which utilize printed circuit boards and insulated wires. These tools do not translate well to e-textiles, which utilize fabric and uninsulated conductive thread. This mismatch of tools and materials can lead to an overly complicated development process for novices. In particular, rapid prototyping tools for traditional embedded systems are poorly matched for e-textile prototyping. This paper presents the ThreadBoard, a tool that supports rapid prototyping of e-textile circuits. With rapid prototyping, students can test circuit designs and identify circuitry errors prior to their sewn project. We present the design process used to iteratively create the ThreadBoard’s layout, with the goal of improving its usability for e-textile creators. 

When learning to code a student must learn both to create a program and then how to debug said program. Novices often start with print statements to help trace code execution and isolate logical errors. Eventually, they adopt advance debugger practices such as breakpoints, "stepping" through code execution, and "watching" variables as their values are updated. Unfortunately for students working with Arduino devices, there are no debugger tools built into the Arduino IDE. Instead, a student would have to move onto a professional IDE like Atmel Studio and/or acquire a hardware debugger. Except, these options have a steep learning curve and are not intended for a student who has just started to learn how to write code. I am developing an Arduino software library, called Pin Status, to assist novice programmers with debugging common logic errors and provide features specific to the e-textile microcontroller, Adafruit Circuit Playground Classic.